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Examiner 
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Applicant(s) 

SUN ET AL 



Art Unit 
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" The MAILING DATE of this communication appears on the cover sheet with the correspondence address - 
Period for Reply 

A SHORTENED STATUTORY PERIOD FOR REPLY IS SET TO EXPIRE 3 MONTH(S) FROM 
THE MAILING DATE OF THIS COMMUNICATION. 

- Extensions of time may be available under the provisions of 37 CFR 1.136(a). In no event, however, may a reply be timely filed 
after SIX (6) MONTHS from the mailing date of this communication. 

- If the period for reply specified above Is less than thirty (30) days, a reply within the statutory minimum of thirty (30) days will be considered timely. 

- If NO period for reply is specified above, the maximum statutory period will apply and will expire SIX (6) MONTHS from the mailing date of this communication. 

- Failure to reply within the set or extended period for reply will, by statute, cause the application to become ABANDONED (35 U.S.C. § 133). 

- Any reply received by the Office later than three months after the mailing date of this communication, even if timely filed, may reduce any 
earned patent term adjustment. See 37 CFR 1.704(b). 

Status 

1)1^ Responsive to connmunication(s) filed on 05 June 2003 . 
2a)n This action is FINAL. 2b)IEI This action is non-final. 

3) n Since this application is in condition for allowance except for formal nriatters, prosecution as to the merits is 

closed in accordance with the practice under Ex parte Quayle, 1 935 CD. 1 1 , 453 O.G. 21 3. 
Disposition of Claims 

4) !3 Claim(s) 1-17 and 37-42 is/are pending in the application. 

4a) Of the above claim(s) is/are withdrawn from consideration. 

5) 0 Claim(s) is/are allowed. 

6) |E1 Claim(s) 1-17 and 37-42 is/are rejected. 
?)□ ClaimXs) is/are objected to. 

8) n Claim(s) are subject to restriction and/or election requirement. 

Application Papers 

9) 0 The specification is objected to by the Examiner. 

1 Q)M The drawing(s) filed on 08 February 2000 is/are: a)D accepted or b)l3 objected to by the Examiner. 
Applicant may not request that any objection to the drawtng(s) be held in abeyance. See 37 CFR 1 .85(a). 

11) 0 The proposed drawing correction filed on is: a)^ approved b)n disapproved by the Examiner. 

If approved, corrected drawings are required in reply to this Office action. 

12) 0 The oath or declaration is objected to by the Examiner. 
Priority under 35 U.S.C. §§ 119 and 120 

13) n Acknowledgment is made of a claim for foreign priority under 35 U.S.C. § 119(a)-(d) or (f). 

a)nAII b)n Some*c)n None of: 

1 .□ Certified copies of the priority documents have been received. 

2.n Certified copies of the priority documents have been received in Application No. . 



3.n Copies of the certified copies of the priority documents have been received in this National Stage 
application from the International Bureau (PCT Rule 17.2(a)). 
* See the attached detailed Office action for a list of the certified copies not received. 

14) 0 Acknowledgment is made of a claim for domestic priority under 35 U.S.C. § 119(e) (to a provisional application). 

a) □ The translation of the foreign language provisional application has been received. 

15) 0 Acknowledgment is made of a claim for domestic priority under 35 U.S.C. §§ 120 and/or 121. 

Attachment(s) 

1 ) M Notice of References Cited (PTO-892) 4) □ Interview Summary (PTO-41 3) Paper No(s). . 

2) O Notice of Draftsperson's Patent Drawing Review (PTO-948) 5) [D Notice of Informal Patent Application (PTO-152) 

3) ^ Information Disclosure Statement(s) (PTO-1449) Paper No(s) 4^7 , 6) □ Other: 
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DETAILED ACTION 



Drawings 



1. 



The drawings are objected to because they are hand drawn with uneven Hnes. A 



proposed drawing correction or corrected drawings are required in reply to the Office action to 
avoid abandonment of the application. The objection to the drawings will not be held in 
abeyance. 



2. Claim 3 is objected to because of the following informalities: The claim recites the 
limitation "the final packet" in line 3. This should be changed to --the last data packet- to be 
consistent with "a last data packet" in line 2. Appropriate correction is required. 



3. The following is a quotation of 35 U.S.C. 103(a) which forms the basis for all 
obviousness rejections set forth in this Office action: 

(a) A patent may not be obtained though the invention is not identically disclosed or described as set forth in 
section 102 of this title, if the differences between the subject matter sought to be patented and the prior art are 
such that the subject matter as a whole would have been obvious at the time the invention was made to a person 
having ordinary skill in the art to which said subject matter pertains. Patentability shall not be negatived by the 
manner in which the invention was made. 



4. Claims 1, 5, 13, 16, 37, 38 and 41 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Klimenko (US Pat. 5,974,547). 



Claim Objections 



Claim Rejections -35 USC §103 



Regarding claims 1, 16, 37 and 41, Klimenko discloses a technique for reliable booting of 
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an operating system to a client computer. The client computer contains a LAN adapter, also 
referred to as a network interface card-NIC (col. 7, lines 11-16). This NIC represents the router 
card of the present invention. The server (50) represents the system controller of the present 
invention and the network (30) represents the bus of the present invention (see Figure 2A). The 
client computer will issue a trivial file transfer protocol (TFTP) request to server (50) by way of 
the NIC. The TFTP server locates and opens this file based on the information provided in the 
TFTP request, then downloads this boot file, LANHD.IMG, to the client computer. The PC 
acknowledges successful download by sending an acknowledgement packet to the server (col. 
1 1, lines 12-26). Klimenko fails to expressly disclose that the information used to locate the file 
is a port address and file type. However, Klimenko does disclose that client hard disk images are 
stored in client image directories unique to a corresponding PC. Each directory has a 1 : 1 
correspondence to its corresponding PC (col. 8, lines 33-50). Klimenko also discloses that each 
NIC has a media access control (MAC) address that identifies that particular NIC (col. 7, lines 
11-16). Also, at a previous step the NIC was given the boot file name, LANHD.IMG (col. 10, 
lines 50-66). At the time the invention was made, it would have been obvious to use the MAC 
address and file type to identify the file to be sent to the NIC. One of ordinary skill in the art 
would have been motivated to use the MAC address to first locate the corresponding directory, 
and the file type, image, to determine which file in the directory to send. 

Regarding claims 5 and 38, Klimenko discloses downloading a LANHDJMG boot file to 
a NIC in a client computer. This downloaded file specifies a file LANHD.INI file for the NIC to 
download next. The LANHD.INI file contains entries including a MAC address, an IP address 



• # 
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of a server and a complete path to a client image file on that server (col. 11, lines 31-39). These 
entries all represent parameters. 

Regarding claim 13, Klimenko discloses that the process of downloading a boot file 
occurs after a user has powered-up cUent PC (10), which includes the NIC (col. 9, lines 56-66). 
It is inherent that if the client PC is powered-up it was at some point previously powered-off 

^ 5. Claims 2-4, 6-12, 14, 15, 17, 39, 40 and 42 are rejected under 35 U.S.C. 103(a) as being 
unpatentable over Klimenko (US Pat. 5,974,547) as applied to claims 1,5, 13, 16, 37, 38 and 41 
above, and flirther in view of K. R. Soilings, "The TFTP Protocol (Revision 2)" (hereinafter RFC 
783). 

Regarding claims 2 and 17, Klimenko discloses using trivial file transfer protocol (TFTP) 
to make the request for the image file. Klimenko also discloses that a TFTP acknowledgement 
packet is sent to the server when the client successfully downloads the file (col. 1 1, lines 17-22). 
Klimenko fails to expressly disclose forming a data packet from the file, wherein the data packet 
is a fixed size and includes a system frame header and a data packet protocol header. RFC 783 
discloses that TFTP that sends packets in fixed length blocks (page 3). Figure 3-1 : Order of 
Headers (page 5) shows a header structure including Local Medium and Internet headers, which 
collectively represent the system frame header of the present invention, and Datagram and TFTP 
headers, which represent the data packet protocol header of the present invention. TFTP also 
specifies that each data packet must be acknowledged by an acknowledgement packet before the 
next packet can be sent (page 3). At the time the invention was made, it would have been 
obvious to a person of ordinary skill in the art to use the fixed size TFTP packet format with the 
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appropriate headers in sending data packets formed from the requested file. One of ordinary skill 
in the art would have been motivated to do this because this protocol is small and easy to 
implement for the purpose of transferring files. 

Regarding claim 3, Klimenko fails to disclose sending a last packet less than the fixed 
size. RFC 783 discloses that a data packet of less than 512 bytes, which is the fixed size, signals 
the termination of a transfer (page 3). At the time the invention was made, it would have been 
obvious to a person of ordinary skill in the art to use this last packet smaller that 512 bytes at the 
end of the file transfer in the invention of Klimenko. One of ordinary skill in the art would have 
been motivated to do this to signal to the NIC that the transfer was complete so that the NIC 
could start using the downloaded file. 

Regarding claim 4, Klimenko fails to disclose retransmitting a data packet to the client if 
the server receives a duplicate acknowledgment packet for the previous packet. RFC 783 
discloses that a lost data packet causes a timeout for the intended recipient, in which case the 
intended recipient retransmits its last packet (page 3). Thus, if the intended recipient is the client 
and a timeout condition occurs, the client would then send an acknowledgement packet for the 
previously received data packet, i.e. a duplicate acknowledgment. At the time the invention was 
made, it would have been obvious to a person of ordinary skill in the art to retransmit a data 
packet formed from the image file of Klimenko in response to receiving a duplicate 
acknowledgement packet. One of ordinary skill in the art would have been motivated to do this 
in order to signal the server that a data packet has not been received and needs to be 
retransmitted. 
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Regarding claims 6 and 40, Klimenko does not expressly disclose a system frame header 
and a data packet protocol header consisting essentially of an operation code, a block number, a 
file type and a checksum. RFC 783 discloses a header structure in Figure 3-1 : Order of Headers 
(page 5) of Local Medium and Internet headers, which represent the system frame header of the 
present invention, and the Datagram and TFTP headers represent the data packet protocol header 
of the present invention. The format for a data packet includes an opcode and a block # (see 
Figure 5-2, page 10). Additionally, TFTP specifies that it may be implemented on top of the 
Internet User Datagram Protocol (UDP or Datagram) (page 2). The User Datagram Header 
includes a checksum (page 15). Thus, this checksum would be included in the data packet 
protocol header. RFC 783 also specifies that a request (RRQ) packet includes a filename in the 
header. This filename represents the file type of the present invention because the file type is 
provided in the filename extension. At the time the invention was made, it would have been 
obvious to a person of ordinary skill in the art to use a system frame header and the data packet 
protocol header format of a TFTP data packet in sending data packets in the invention of 
Klimenko. It also would have been obvious to include the filename, normally only included in 
the TFTP RRQ packet, in the header of the data packet. One of ordinary skill in the art would 
have been motivated to use the system frame header and data packet protocol header to be 
compliant with the TFTP standard. One of ordinary skill in the art would have been motivated to 
include the filename in the TFTP data packet header so that the NIC on the client computer 
would be able to determine which packets belong to which file if more than one file is being 
downloaded. 
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Regarding claim 7, Klimenko fails to disclose that the acknowledgement packet consists 
essentially of a system frame header, and acknowledgement code, and a block number. RFC 783 
discloses a format for an ACK packet that contains an opcode, which represents the 
acknowledgement code, and block # (see Figure 5-3, page 10). The system frame header is 
shown in Figure 3-1 (page 5). At the time the invention was made, it would have been obvious 
to a person of ordinary skill in the art to use this format of an acknowledgement packet in 
acknowledging the received file from the server in the invention of Klimenko. One of ordinary 
skill in the art would have been motivated to do this so that the server would know which packets 
have been sent successfially and which ones need to be retransmitted. 

Regarding claims 8-10, Klimenko discloses a media access control (MAC) address of the 
NIC that is 12 characters long in hexidecimal format, or 6 bytes long if represented in binary 
(col. 10, line 5). The server also has a MAC address (col. 1 1, lines 35-37). Klimenko fails to 
disclose a system frame header that specifies the addresses of the router card and system 
controller. RFC 783 discloses a system frame header composed of Local Medium and Internet 
headers (Figure 3-1, page 5). At the time the invention was made, it would have been obvious to 
send the MAC addresses of the NIC and server in the Local Medium part of a system frame 
header in the invention of Klimenko. One of ordinary skill in the art would have been motivated 
to do this so that the packet would be routed to the correction destination NIC and that the 
receiving NIC was sure that this packet was coming from the server. 

Regarding claims 11, 12, 39 and 42, Klimenko discloses a media access control (MAC) 
address of the NIC that is 12 characters long in hexidecimal format, or 6 bytes long if 
represented in binary (col. 10, line 5). The server also has a MAC address (col. 1 1, lines 35-37). 
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Klimenko fails to disclose a system frame header that specifies the addresses of the router card 
and system controller, a request code, and a file type in the request packet. RFC 783 discloses a 
system frame header composed of Local Medium and Internet headers (Figure 3-1, page 5). 
RFC 783 also discloses a request packet format that includes an opcode, which is the request 
code of the present invention, and a filename, which represents the file type of the present 
invention (see Figure 5-1, page 8). At the time the invention was made, it would have been 
obvious to send the MAC addresses of the NIC and server in the Local Medium part of a system 
frame header in the invention of Klimenko. It also would have been obvious to include a request 
code and the file type in the request packet. One of ordinary skill in the art would have been 
motivated to do this so that the packet would be routed to the correction destination NIC and that 
the receiving NIC was sure that this packet was coming from the server. One would have been 
motivated to include the request code and file type to be compliant with the TFTP format of a 
request packet. 

Regarding claims 14 and 15, Klimenko discloses that the process of downloading a boot 
file occurs after a user has powered-up client PC (10), which includes the NIC (col. 9, lines 56- 
66). It is inherent that if the client PC is powered-up it was at some point previously powered- 



off 



Conclusion 



The prior art made of record and not relied upon is considered pertinent to applicant's 



disclosure. 



- Bahlman et al. (US Pat. 6,170,008) On-the-Fly Trivial File Transfer Protocol 




• 
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- Bailey et al. (US Pat. 6,185,623) Method and System for Trivial File Transfer Protocol 
(TFTP) Subnet Broadcast 

- Hong et al. (US Pat. 563,821) Channel Bonding in a Remote Communications Server 

System 

7. Any inquiry concerning this communication, or earlier communications from the 
examiner should be directed to Thomas Volper whose telephone number is 703-305-8405 and 
fax number is 703-746-9467, The examiner can normally be reached between 8:30am and 
6:00pm M-F. 

If attempts to reach the examiner by telephone are unsuccessful, the examiner's 
supervisor, Huy Vu, can be reached at 703-308-6602. Any inquiry of a general nature or relating 
to the status of this application or proceeding should be directed to the receptionist whose 
telephone number is 703-305-4750. / 



July 16, 2003 



tev 




